Credential-free user login to remotely executed applications

ABSTRACT

Provided is a process including: receiving, with an intermediary server, a request to access web content at a web server; submitting, from the intermediary server a value by which possession of an access credential is demonstrated, wherein the value is withheld from the client web browser; receiving, by the intermediary web browser, instructions to store in web browser memory an access token; and sending, from the intermediary server, to the client web browser executing on the client computing device, instructions to store the access token in browser memory of the client web browser, thereby authenticating the client web browser without the client web browser having access to the value by which possession of the access credential is demonstrated.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent is a continuation of U.S. patent application Ser. No.16/013,478, titled CREDENTIAL-FREE USER LOGIN TO REMOTELY EXECUTEDAPPLICATIONS, filed 20 Jun. 2018, which is a continuation of U.S. patentapplication Ser. No. 15/809,500, titled CREDENTIAL-FREE USER LOGIN TOREMOTELY EXECUTED APPLICATIONS, filed 10 Nov. 2017, issued as U.S. Pat.No. 10,027,649, which is a continuation of U.S. patent application Ser.No. 15/675,434, titled CREDENTIAL-FREE USER LOGIN TO REMOTELY EXECUTEDAPPLICATIONS, filed 11 Aug. 2017, issued as U.S. Pat. No. 9,866,545,which claims the benefit of U.S. Provisional Patent Application62/374,313, titled CREDENTIAL-FREE USER LOGIN TO REMOTELY EXECUTEDAPPLICATIONS, filed 12 Aug. 2016; and U.S. patent application Ser. No.15/675,434 is a continuation-in-part of U.S. patent application Ser. No.15/171,347, titled COMPUTER SECURITY AND USAGE-ANALYSIS SYSTEM, filed 2Jun. 2016, which claims the benefit of U.S. Provisional PatentApplication 62/169,823, filed 2 Jun. 2015. The entire content of eachaforementioned patent filing is hereby incorporated by reference.

BACKGROUND 1. Field

The present disclosure relates generally to cybersecurity and, morespecifically, to credential management.

2. Description of the Related Art

Often entities, like businesses, governments, and other organizations,provide access for their members (e.g., employees) to various remoteapplications, like web-based software-as-a-service (SaaS) applications,and native (locally executed outside of a thin client) applications. Forinstance, users may access various on-premises or SaaS web-basedapplication, like online email, calendaring, office productivity,enterprise-resource planning, customer relationship management, projectmanagement, or other applications. In many cases, sensitive companyinformation is maintained in such applications.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process, including: receiving, via a firstnetwork, with an intermediary server, a request to access web content ata web content server, wherein: the request is received from a client webbrowser executing on a client computing device, the client computingdevice being a different computing device from the intermediary server;at least some communications between the client web browser and at leastsome remote websites accessed by the client web browser are relayed bythe intermediary server; and the intermediary server comprises anintermediary web browser configured to cooperate with the client webbrowser to form a distributed web browser in which a first subset ofwebpage state of remotely hosted webpages is mirrored on both the clientweb browser and the intermediary server and a second subset of webpagestate of the remotely hosted webpages is formed on the intermediaryserver but not on the client web browser; determining, at theintermediary server, that the user needs to be authenticated beforeaccessing at least some content reachable via the web content server,wherein an access credential by which the user is authenticated isaccessible to the intermediary server but not to the user of the clientcomputing device; submitting, from the intermediary server, to a remoteserver configured to authenticate the user, via a network socket bywhich the intermediary web browser is connected to a second network, avalue by which possession of the access credential is demonstrated,wherein the value is part of the second subset of webpage state and iswithheld from the client web browser; receiving, by the intermediary webbrowser, via the network socket by which the intermediary web browser isconnected to the second network, instructions to store in web browsermemory an access token, poof of possession of which is to be sent withsubsequent messages to one or more severs hosting the at least somecontent to demonstrate the respective message is from an authenticateduser; and sending, from the intermediary server, to the client webbrowser executing on the client computing device, via the first network,instructions to store the access token in browser memory of the clientweb browser, wherein: the instructions cause the client web browser tosend messages with a value that demonstrates possession of the accesstoken, thereby authenticating the client web browser without the clientweb browser having access to the value by which possession of the accesscredential is demonstrated.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by a data processing apparatuscause the data processing apparatus to perform operations including theabove-mentioned process.

Some aspects include a system, including: one or more processors; andmemory storing instructions that when executed by the processors causethe processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a combined logical and physical architecture block diagramthat shows an example of a computing environment in which an identitymanagement application in accordance with some embodiments of thepresent techniques may operate;

FIG. 2 is a flowchart that shows an example of a process by which clientweb browsers may be logged into third-party web applications withoutmaking access credentials available to users or the client web browsersin accordance with some embodiments of the present techniques;

FIG. 3 is a flowchart that shows an example of a process by whichpermissions to access a native application executing on a clientcomputing device may be implemented in accordance with some embodimentsof the present techniques;

FIG. 4 is a flowchart that shows an example of a process by which anongoing authenticated session between a client web browser and athird-party server may be terminated without waiting for theauthentication token to expire in accordance with some embodiments ofthe present techniques;

FIG. 5 is a flowchart that shows an example of a process by which acentralized permission management service may be provided in accordancewith some embodiments of the present techniques;

FIG. 6 is an example of a centralized user interface by which userpermissions may be managed for heterogenous applications in accordancewith some embodiments of the present techniques;

FIG. 7 shows an example of a tamper-evident, immutable data repositoryin which records may be stored in accordance with some embodiments ofthe present techniques; and

FIG. 8 shows an example of a computing device by which the presenttechniques may be implemented.

While the present techniques are susceptible to various modificationsand alternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit thepresent techniques to the particular form disclosed, but to thecontrary, the intention is to cover all modifications, equivalents, andalternatives falling within the spirit and scope of the presenttechniques as defined by the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field ofcybersecurity. Indeed, the inventors wish to emphasize the difficulty ofrecognizing those problems that are nascent and will become much moreapparent in the future should trends in industry continue as theinventors expect. Further, because multiple problems are addressed, itshould be understood that some embodiments are problem-specific, and notall embodiments address every problem with traditional systems describedherein or provide every benefit described herein. That said,improvements that solve various permutations of these problems aredescribed below.

A variety of problems relating to permission management are addressed byvarious versions of techniques described below. These differenttechniques can be used together, synergistically in some cases, so theirdescriptions are grouped into a single description that will be filed inmultiple patent applications with different claim sets targeting thedifferent techniques and combinations thereof. In view of this approach,it should be emphasized that the techniques are also independentlyuseful and may be deployed in isolation from one another or in anypermutation combining the different subsets of techniques, none of whichto suggest that any other description herein is limiting. Conceptuallyrelated groups of these techniques are preceded by headings below. Theseheadings should not be read as suggesting that the subject matterunderneath different headings may not be combined, that every embodimentdescribed under the heading has all of the features of the heading, orthat every feature under a given heading must be present in anembodiment consistent with the corresponding conceptually related groupof techniques, again which is not to suggest that any other descriptionis limiting.

These techniques are best understood in view of an example computingenvironment 10 shown in FIG. 1, which shows an example of a computingenvironment 10 in which these techniques, either individually ortogether, may be implemented. In some embodiments, the components ofFIG. 1 are implemented with a plurality of the computing devicesdescribed below with reference to FIG. 8 to execute the operationsdescribed in FIGS. 2-5, in some cases responsive to the user interfacein FIG. 6, and in some cases on the data structure of FIG. 7.

In some embodiments, the computing environment 10 includes an identitymanagement system 12 configured to exercise control over permissionsgranted to users to access various native applications ornetwork-accessible applications, such as web applications, like SaaSapplications or applications on a private cloud. In some embodiments, asdescribed in greater detail below, the identity management system 12 maybe configured to store access credentials in a relatively securetamper-evident, immutable data store. Further, some embodiments may beconfigured to log management and access events in a tamper-evident,immutable data store. These data stores may deter threat actors, andincluding otherwise trusted internal actors, from engaging in maliciousbehavior, due to the challenge of accessing credentials in these datarepositories and due to likely inevitable discovery of the behavior invirtue of the immutably logged events. That said, embodiments are notlimited to systems that afford these benefits, and some embodiments mayuse traditional data stores for storing this information, which is notto suggest that any other description herein is limiting.

In some embodiments, the identity management system 12 manages user'sability to access these resources on a plurality of computing devices14, in some cases via a private network 18 separated by a firewall 20from the public Internet 22. In some embodiments, some of thenetwork-accessible applications may be hosted by one or more third partydestination servers 16, which may include distributed web applications,in some cases with some servers managing authentication andauthorization, and other servers providing services, for example, webcontent by which the services are delivered, and which is rendered byclient computing devices in thin client user interfaces, like web pages.

In some embodiments, the private network 18 is a corporate network ornetwork of an organization, for example, on a private subnet InternetProtocol network. In some embodiments, the private network 18 includesencrypted connections between client computing devices 14 and variousinternal servers. In some embodiments, the client computing devices 14are end-user computing devices, or in some cases the client computingdevices are servers executing one or more applications, such asmonolithic applications or services of distributed service-orientedarchitecture applications, for example, in an on-premises installationby which other end user computing devices of an organization accessresources via network 18. In some embodiments, the private network 18hosts a virtual private network. In some embodiments, the identitymanagement system 12 is on the private network 18, or in some cases theidentity management system 12 may be accessed via the public Internet22, which is not to suggest that a virtual private network may not spanthe public Internet 22.

In some embodiments, the illustrated components may be distributedgeographically, for example, with various components more than 100 or1000 km apart, for example, distributed over United States, NorthAmerica, or the world. In the illustrated embodiment, two clientcomputing devices 14 are illustrated, but commercial embodiments areexpected to include substantially more, for example, more than 100, morethan 1000, or more than 10,000 client computing devices for a givenorganization having an account by which the identity management system12 is used to manage permissions for the client computing devices 14. Insome embodiments, multiple tenants may share the identity managementsystem 12, for example, in a SaaS delivery model, for instance, morethan 5, more than 50, or more than 500 different tenants, in some caseswith concurrent sessions. Or in some cases, the identity managementsystem 12 may be deployed in on-premises installation or in a virtualprivate cloud in which an instance is deployed for an individual tenant.

Two destination servers 16 are illustrated, but commercial embodimentsare again expected to include substantially more, for example, more than20, more than 50, or more than 500 different destination servers. Theterm “destination” is used to refer to an external place where variousresources are accessed and serves to distinguish “intermediary” serversdescribed below, through which some exchanges with a destination servermay take place. In some embodiments notwithstanding the singular term“server,” the destination servers 16 may each be multi-serviceapplications, such as distributed applications having a plurality ofcomputing devices, such as multiple servers deployed behind loadbalancers and providing various services by which requests are servicedand a web application or other application program interface is exposedfor use by client computing devices 14. In some embodiments, thedestination servers 16 may be controlled by a third party that isdifferent from an organization, such as a company, for which permissionsare managed for members of the organization, such as users, by theidentity management system 12. In some embodiments, the differentdestination servers 16 may support, and in some cases require, thataccess to resources hosted by those servers be authorized through anauthentication process. In some embodiments, authentication may includesupplying a user name and access credential (e.g., a password or othersecret string), or value demonstrating possession of the access creditcredential, for example by submitting a cryptographic hash of the accesscredential, or a digital signature that can be verified in an asymmetricencryption protocol as having originated from a party associated with apublic key, such as a public key serving as a username, or uniquelyassociated with username. In some embodiments, the destination servers16 may include servers that perform authentication on behalf of otherdestination servers, for example, certain destination serversimplementing OAuth or OAuth 2 protocol. Examples of destination servers16 include those hosting web-based email accounts, documentrepositories, chat applications, web-based office suite applications,web-based enterprise resource management applications, web-based humanresources management applications, web-based customer relationshipmanagement applications, and the like. In some embodiments, thesedifferent destination servers may have different application programinterfaces by which permission attributes of user accounts are managedand by which users are authenticated in a given session where a userrequests to access resources of the respective destination server 16.

In some embodiments, the client computing devices 14 are desktopcomputing devices, laptop computing devices, tablet computing devices,smart phones, printers, copiers, scanners, or various Internet of thingsappliance is, like smart televisions, smart refrigerators, industrialcontrols equipment, industrial sensors, healthcare equipment, autonomousdrones, self-driving vehicles, human-piloted vehicles, and the like. Insome embodiments, some of the client computing devices 14 includeservers by which other client computing devices access resources, suchas client computing devices hosting monolithic applications accessedover a network, or client computing devices that host various servicesin a service-oriented architecture (e.g., a microservices architecture)distributed application by which other client computing devices accessresources.

In some embodiments, the identity management system 12 includes apermission-management application 24, an intermediary server 26 (orelastically scalable set thereof), and a tamper-evident, immutable datastore 28. In some embodiments, these components may cooperate toimplement one or more of the processes, interfaces, and data structuresdescribed below with reference to FIGS. 2 through 7. In someembodiments, the permission-management application 24 may provide acentralized application by which users' permissions may be managedacross a heterogeneous mix of native applications and network accessibleapplications, in some cases with a relatively intuitive drag-and-dropinterface exposed to one or more administrator client computing devices,such as one of the client computing devices 14. In some embodiments, theintermediary server 26 may include functionality by which same-originpolicies on web browsers on client computing devices 14 arecircumvented, such that the intermediary server 26 may manage browsermemory otherwise only accessible to a content from a domain that wroteto the browser memory, such as content from a domain from one of thedestination servers 16, thereby, in some cases, affording a mechanism bywhich authenticated sessions may be terminated, even in the absence ofan agent executing on a user computing device, and even before anauthentication token (or other type of access token) associated with theauthenticated session times out, as described in greater detail below.In some embodiments, the tamper-evident immutable data repository 28 mayprovide a data structure and mechanism by which access requests aresecurely logged and credentials, permissions, and adjustments theretoare securely documented in a manner that deters threat actors fromattempting to modify these relatively sensitive records, in some caseswith a data structure like that described below with reference to FIG.7.

In some embodiments, the permission-management application 24 includesan application program interface translator 30, a controller 32, a userinterface generator 34, a role-repository 36, a permission repository38, a native-application repository 40, a group-repository 42, apolicy-repository 44, and a network-accessible application repository46. In some embodiments, these repositories 36 through 46, or subsetsthereof, may be stored in the tamper-evident, immutable data store 28 orin a traditional data store, such as a relational database or a noSQLdatabase. In some embodiments, the permission-management application mayexecute a process described in greater detail below with reference toFIG. 5, responsive to a user interface described in greater detail belowwith reference to FIG. 6, to afford a centralized interface by which aplurality of different native and remotely hosted applications aremanaged with respect to user permissions, for example, permissionsspecifying resources a given user with a given credential is authorizedto access on the respective application.

The various repositories 36 through 46 may store data in service ofthese types of functionality. In some embodiments, the role-repository36 may store records that map individual users to roles, such as a jobtitle, for example, in a hierarchical taxonomy of job titles, and someembodiments may maintain records in the policy-repository 44 that maptitles to various sets of permissions in various managed applications.In some embodiments, the permissions repository 38 may store a currentmapping between users and sets of permissions in various applications,in some cases populated based on operations in which the records in therole-repository 36 are joined with records in the policy-repository 44.In some embodiments, the native-application repository 48 may store aninventory of native applications for which permissions are granted, and,in some cases, an inventory of user computing devices upon which thenative applications are installed, in some cases with unique identifiersassociated with each installed instance, in some cases associated withidentifiers of the client computing devices, such as MAC addresses,Internet Protocol addresses, and the like. In some embodiments, thegroup-repository 42 may include records by which users are assigned togroups, for example, hierarchies of groups, for instance, differentdepartments and teams within an organization. In some embodiments,records in the group-repository may be joined with rules in thepolicy-repository to determine which permissions are granted or revoked.For example, users within an accounting group may be granted permissionsbased on such a mapping in the group-repository 42 according to a rulein the policy-repository 44. In some embodiments, default permissionsmay be determined based on a join operation between the role-repository36, the group-repository 42, and the policy-repository 44. In someembodiments, different policies may be associated with different tenantsin the policy-repository 44 or different business units.

In some embodiments, the network-accessible application repository 46may store application-program interface translation records, such astemplates, by which permission management requests received in a uniformformat from client computing devices 14 are translated into anapplication program interface schema specific to that of one of thedestination-servers 16, for example, accommodating different schemas foradding or removing permission of different application programinterfaces exposed by different third parties operating the differentdestination servers 16. In some embodiments, the network-accessibleapplication repository 46 may further include records that defineclient-side data structures formed in web browser state in the course ofrendering web content provided by different third parties operatingdifferent destination servers 16. Examples include addresses, forexample, key terms in a namespace of a web application, like names ofcookies, names of local Storage objects, or primary keys in a SQLitedatabase, populated within browser memory of a web browser on one of theclient computing devices 14 responsive to commands sent by one of thedestination servers 16. Examples include an identifier of a cookiestoring an authentication token by which a client computing device 14demonstrates that a given message is part of an authenticated session ina message to one of the destination servers 16.

In some embodiments, the controller 32 may coordinate the operation ofthe other components of the permission-management application 24, insome cases executing the process described below with reference to FIG.5 in cooperation with these components.

In some embodiments, the application program interface translator 30 maybe configured to interface with web-browser memory based on addresses ina namespace of web browser state defined by content a destination server16 and identified with records in the network-accessible applicationrepository 46. For example, browser memory may be accessed based on anidentifier of a network-accessible application upon which operations areto be performed, for instance, translating a command to de-permission acurrent session in a command that causes a cookie storing anauthentication token on a client web browser to be deleted or otherwisemodified such that the authentication token is inoperative, or composingor otherwise selecting scripting instructions to be embedded intocontent sent from a destination server to a client computing device,such that the web browser of the client computing device is renderedresponsive to a de-permission command from the permission-managementapplication 24 to delete (or otherwise modify to render inoperativevalues within) such client-side browser memory.

Further, the application program interface translator 30 may beoperative to translate permission-related management request fromadministrator client computing devices into commands sent to differentdestination servers 16 to modify permissions stored in recordsaccessible to the destination servers 16, for example, in associateduser accounts hosted by different destination servers 16.

In some embodiments, the user interface generator 34 is configured toform instructions sent to client computing devices 14, for example,webpage markup, scripting routines, and styling instructions, along withother resources, like images and structured data, by which userinterfaces are rendered, for example, in web browsers. In someembodiments, the user interface generator 34 is configured to send (andprocess instructions from) the user interface described below withreference to FIG. 6. Or in some cases, the user-interface interfacegenerator 34 exposes an application program interface accessed by anative application on one of the administrator client-computing devices.Sending data by which a user interface is constructed is an example ofsending a user interface.

In some embodiments, the intermediary server 26 is configured toimplement processes described below in greater detail with reference toFIGS. 2 through 4. In some embodiments, the intermediary server 26includes a controller 48, a browser configurator 50, a headless browser52, a message filter 54, a credential access module 56, a credentialsubmission module 58, a client-browser memory editor 60, and a messageeditor 62. In some embodiments, multiple instances of the intermediaryserver 26, and in some cases the other illustrated components, may beelastically scaled, for example, with various tools for orchestratingadditional instances, for example, by spinning up additional containersor virtual machines and deploying images to those computationalentities, or spinning down such entities as demand subsides. In someembodiments, one intermediary server 26 may be instantiated for eachcurrent session between a client computing device 14 and a destinationserver 16, or in some cases, different instances of the headless browser52 may be instantiated for each instance.

In some embodiments, the controller 48 may execute the below-describeprocesses and coordinate the operation of the other components of theintermediary server 26. In some embodiments, the controller 48 maymonitor a network socket on the private network 18 by which a clientcomputing device 14 attempts to communicate with one of the destinationservers 16, and the controller 48 may monitor another network socket(which may be specified by an IP address and port number), either on theprivate network 18 or the public Internet 22, by which those messagesare related to the destination server 16, in some cases, withmodifications like those described below.

In some embodiments, the browser configurator 50 may be operative toconfigure the headless browser 52, for example, upon instantiating orrepurposing a given instance of the headless browser 52. In someembodiments, the browser configurator 50 may obtain, either from memoryor by parsing hypertext transport protocol requests or otherwiseinterrogating a web browser on a client computing device 14, a browserfingerprint, which in some cases may include attributes of the computingdevice executing the browser. In some embodiments, the browserconfigurator 50 may receive a browser fingerprint by parsing auser-agent string from a web browser, for example, in a header of ahypertext transport protocol request sent to the intermediary server 26from a web browser executing on a client computing device 14. In somecases, the user-agent string may identify a web browser, a version ofthe web browser, an operating system, a version of the operating system,a window size, a display size, a processor, an amount of memory, whetherthe user interface is touch-enabled, and the like. In some embodiments,the browser configurator 50 may be configured to form an instance of aheadless browser 52 that has some or all of these attributes, forexample, with a matching or partially overlapping subset of fieldswithin a user agent string of the headless browser 52. In someembodiments, this may cause content negotiation implemented with theheadless browser 52 to yield web-based content that will render properlywhen relayed to a web browser on a client computing device 14.

In some embodiments, the headless browser 52 may be a headless browserconfigured to render webpage content, thereby forming a document objectmodel or virtual document object model in browser state. Or in someembodiments, the browser 52 is not headless and causes a display to bepresented. In some embodiments, the headless browser is furtherconfigured to execute scripting language instructions, such asJavaScript™ or WebAssembly in received web content, which in some casesmay include modifying a document object model, a virtual document objectmodel, or records in local storage of a browser, for instance withincookies, localStorage objects, or SQLite databases in client-side webpage state of a browser. In some embodiments, modifying local storagemay include writing cookies or other instances of these types ofstorage, deleting records, or modifying records, and some embodimentsmay be configured for reading records. In some embodiments, the headlessbrowser 52 may be instantiated with a webdriver object, for example,provided by the Selenium™ headless web browser.

In some embodiments, the headless browser 52, like browsers on theclient computing devices 14, may implement a same-origin policy. As aresult, in some cases, the browser may prohibit content from one domainfrom accessing local storage of the web browser written by content fromanother domain. The same-origin policy is a technique by which securityis enforced across websites and which, for example, prevents contentfrom a malicious website from reading values written to cookies by, forexample, an email website or a banking website and obtaining informationlike access tokens or passwords by which a sensitive account might becompromised. As noted above, the web browser 74 described belowimplements a same origin policy, for instance, as defined in RFC 6454.

In some embodiments, the intermediary server 26 may include a messagefilter 54 configured to classify messages sent between the clientcomputing device 14 and a destination server 16 as pertaining topermission information managed by the permission-management application,for instance, via the intermediary server 26. Examples include messagespertaining to authentication protocols. For instance, in someembodiments, the message filter 46 may classify requests from clientcomputing devices or content from destination servers 16 as pertainingto a user interface by which a user logs into a service hosted by one ofthe destination server 16, for instance, a webpage user interface bywhich a user submits a username and password or other valuedemonstrating possession of the password, such as a cryptographic hashof the password formed client-side. Some embodiments may be configuredto detect messages from a destination server 16 containing such a userinterface, in some cases based on records in the network-accessibleapplication repository by which filters are configured for a givendestination server 16 or corresponding application hosted on thatdestination server 16. Examples include regular expressions configuredto detect keywords in web content, such as hypertext markup, scriptinglanguages, styling, or resources like images, known to be present withinsuch interfaces.

In some embodiments, the headless browser 52 may maintain a secureencrypted connection between the headless browser 52 and one of thedestination servers 16, for example, an SSL or TLS connected sessionover HTTPs. In some embodiments, the headless browser 52 may decryptcontent received from the destination server 16 according to theseprotocols and encrypt messages sent to these servers according to theseprotocols. Upon decrypting, though, aspects of webpage state in theheadless browser 52 may be accessible to the controller 48 in order togive effect to some of the processes described below, in someembodiments.

In some embodiments, the credential access module 56 may be configuredto retrieve credentials from the credential repository 62 in thetamper-evident, immutable data store 28, for example, by querying thedata structure described below with reference to FIG. 7. In someembodiments, as described in greater detail below, credentials to accessa given destination server 16 may be withheld from client computingdevices 14, for instance, preventing users or web browsers on clientcomputing devices from accessing passwords by which sessions areauthenticated with various third-party web applications.

In some embodiments, the credential submission module 58 is configuredto log users into authenticated interactions with the destinationservers 16, such as into authenticated sessions. In some embodiments,upon the message filter 54 classifying received content as being a userinterface by which a user logs in, some embodiments of the credentialsubmission module 58 may programmatically (which is not to suggest thatother operations are not programmatic, as all operations not designatedas human performed herein should be read as programmatic, e.g.,automatic) populate inputs of the user interface, for example, text boxinputs with credentials, and in some cases, user names. In someembodiments, the network-accessible application repository 46 mayfurther maintain instructions by which a document object model orvirtual document object model encoding the logging user interface istraversed or otherwise parsed to identify and map webpage elements tofields submitted during a login, for example, identifying a documentobject model element corresponding to a text box input by which a username is submitted and another text box input by which a password, orvalue demonstrating possession of the password, is submitted. Someembodiments may parse the document object model to identify these inputsand programmatically insert passwords, and in some cases, user namescorresponding to a given user for which accessories requested. In somecases, the user interface is not sent to the client computing device 14,or in some cases a subset of the user interface is sent to the clientcomputing device, for example, a subset formed by omitting or otherwisemodifying a field by which a password is input, while permitting theusers supply a username. In some embodiments, user interface elements bywhich a captcha is presented or by which a second factor in two-factorauthentication is entered is passed through to the client computingdevice 14, and some embodiments may then relay a response from the user,or update a mirror of a web browser state in the headless browser 52based on user responses return to the intermediary server 26 inaccordance with the techniques described below.

In some embodiments, the client-browser memory editor 60 is configuredto modify records in a web browser executing on a client computingdevice 14 and, in some cases, local browser memory records mirrored inthe headless browser 52. In some embodiments, the client-browser memoryeditor 60 may be configured to access records at addresses specifiedwith records in the network-accessible application repository 46corresponding to an application being accessed to, for example, insertin browser memory, such as a cookie, an authentication token received bythe headless browser 52 in a secure encrypted exchange with one of thedestination servers 16, upon a successful submission of a credential bythe module 58, thereby rendering the instance of the web browsermirrored on a client computing device 14 authenticated to engage insubsequent messaging with the destination server 16.

In some embodiments, authenticated messages may have the authenticationtoken, or a value demonstrating possession of the authentication token,such as a value that is a cryptographic hash of the authenticationtoken, or a value digitally signed with an asymmetric encryptionprotocol, by the authentication token, appended to messages. Destinationservers 16 may parse the value demonstrating possession of theauthentication token from messages received from the client computingdevices 14, for example, via the intermediary server 26, and determinewhether the value correctly demonstrates possession of theauthentication token and thereby determine, in response to the valuecorrectly demonstrating possession, that the message is authenticated bya party that was authorized via the credential submission from themodule 58.

In another example, the client-browser memory editor 60 may beconfigured to delete or otherwise modify such records to remove theability of a client computing device web browser to send authenticatedmessages under a current authenticated session in accordance with thetechniques described in greater detail below with reference to FIG. 4.In some embodiments, this technique may be implemented withoutimplementing the techniques by which access credentials are withheldfrom users or client computing devices 14. For example, some embodimentsmay permit the user to supply the password, while still retaining theability to terminate an authenticated session without waiting for theaccess token to expire, which is not to suggest that any other featuredescribed herein is required in all embodiments.

In some embodiments, the message editor 62 may be configured to editmessages sent between the client computing device 14, such as a webbrowser executing on the client computing device 14, and one or more ofthe destination servers 16. In some cases, this may include editingfields in headers of various protocols by which data is exchanged. Someembodiments may be configured to modify origin host fields in anapplication layer protocol, such as a hypertext transport protocol,header (which includes secure variants thereof and other transportprotocols, like SPDY). In some cases, modifying origin host fields mayinclude composing new headers with the same content or copies thereof,or in some cases extant copies may be modified, for example byoverwriting values in various fields. In some embodiments, the hostorigin field may be accompanied with or other origin parameters, such asa protocol identifier and a port number of a computational entity fromwhich a given message originated. In some embodiments, modifying mayinclude modifying the host origin field to identify the intermediaryserver 26 as a host, rather than a destination server 16 as host. Insome embodiments, this may include forming a version of anapplication-layer message in which the host origin field includes auniform resource identifier of the intermediary server 26, such as onemapped to the intermediary server 26 by a domain name service the clientcomputing device 14 web browser is configured to access to resolveuniform resource identifiers into Internet Protocol addresses. In someembodiments, a URI of the destination server 16 may be replaced in themodified version (which may be a new copy formed that never includes theURI of the destination server) with a URI of the identity managementsystem intermediary server 26. As a result, in some embodiments, theintermediary server 26 may be able to access web browser memory on theclient computing device written to by content from the destinationserver 16 without being blocked by a same-origin policy implemented bythe web browser on the client computing device 14.

In some embodiments, other techniques for circumventing the same-originpolicy may be implemented. In some embodiments, the client computingdevice 14 may be configured to access a private domain name servicecontrolled by the permission-management application 24 to resolveInternet Protocol addresses from uniform resource identifiers, such asuniform resource locators. In some embodiments, thepermission-management application 24 may be configured to modify amapping between Internet Protocol addresses responsive to adetermination that web browser memory needs to be remotely accessed,such that an Internet Protocol address and port number of a networksocket of their intermediary server 26 is mapped to a uniform resourceidentifier formerly mapped to a corresponding destination server 16.

In some embodiments, the message editor 62 may append authenticationtokens, or values demonstrating possession of authentication tokens, tomessages from client computing devices to destination servers 16,without the authentication token being provided to client computingdevice's web browser memory, thereby permitting selective management ofauthenticated messages at the intermediary server 26, without needing toaccess the authentication token in web browser memory in some cases.

Or some embodiments may only manage native applications and not managenetwork-accessible applications, or some embodiments may manage nativeapplications and server-side user account settings, without exercisingcontrol of ongoing currently authenticated sessions, which is not tosuggest that any other feature described herein is limiting.

In some embodiments, the tamper-evident immutable data store 28 mayimplement the techniques described in a patent application titledIMMUTABLE DATASTORE FOR LOW-LATENCY READING AND WRITING OF LARGE DATASETS, filed on the same day as this application, the contents of whichare hereby incorporated by reference. In some embodiments, this mayinclude storing credentials and logged access and permission events inthe data structure described below with reference to FIG. 7, in somecases in replicated instances of that data structure, and in some caseswith different instances of that data structure for credential data andfor log data.

In some embodiments, each of the client computing devices 14 may executean operating system 68 in which an agent 70, a native application 72,and a web browser 74 may execute. In some embodiments, the web browser74 may be characterized as a thin client application by which thedestination servers resources 16 are accessed.

In some embodiments, the operating system is Windows™, Mac OS™, z/OS™,iOS™, Android™, or another version of Linux™. In some embodiments, theagent 70 is configured to launch upon booting of the operating system68. In some embodiments, the agent 70 establishes a persistentconnection with the permission-management application 24 upon beinglaunched, for example, periodically polling the permission-managementapplication 24, or connecting to a network socket of the clientcomputing device 14, via a network stack of the operating system 68, andsending a message to the permission-management application 24 uponlaunching identifying the Internet protocol address and port number ofthe network socket, such that the agent 70 may receive messages from thepermission-management application 24 in real time via a continuousconnection. In some embodiments, the agent 70 may be configured toexecute operations described in greater detail below with reference toFIG. 3 by which the native application 72 is controlled. In someembodiments, the agent 70 may include a secure region of memory in whichaccess credentials for the native application 72 are stored. In someembodiments, the secure region of memory may be encrypted, and in somecases a key to decrypt the secure region of memory may be stored withina secure element or other hard-ware segregated region of protectedmemory of the client computing device 14. Thus, in some cases, the agent70 may be operative to permit access to the native application 72, bydetecting that the native application 72 is being launched, anddecrypting and accessing the access credential, even in the absence ofnetwork access. Or in some embodiments, the access credential for thenative application 72 may instead be stored in the credential datarepository 64 and accessed via networks to provide enhanced security.

In some embodiments, the native application 72 is a desktop applicationexecuting on desktop or laptop computer or a native applicationexecuting on a mobile computing device, like a smart phone, for example,a native application downloaded from the app store of a provider of anoperating system 68. Examples include email clients, office productivitysuite applications, spreadsheet applications, word processingapplications, computer aided design applications, and the like. In someembodiments, the web browser 74 is also under the control of the agent70.

Credential-Free User Login to Remotely Executed Applications

Often business employees access web-based or native applications wherecredentials need to be shared amongst multiple individuals within anorganization. For instance, a group of users may share a login usernameand password for an account to some SaaS web-based application, likeonline email, calendaring, office productivity, enterprise-resourceplanning, customer relationship management, project management, or otherapplications. In many cases, sensitive company information is maintainedin such applications.

Yet employees often fail to adequately protect login credentials. Manyleaks are due to human failings. It is common for employees to writedown the credentials on a notepad visible on their desk, potentiallyexposing the sensitive information to anyone walking through an office.Or in many cases, employees choose simple passwords that are easy tobrute force. Some threats are intentional. Threat actors often engage inrelatively sophisticated spear phishing campaigns by which employees aretricked into revealing their login credentials. Keyloggers on employeecomputers represent yet another attack vector. And in many cases,begrudged employees intentionally abuse and disclose login credentials,e.g., selling such credentials on the dark web.

Some embodiments include a system designed to be used by businessemployees where they are required to access web-based or nativeapplications where credentials might otherwise need to be shared amongstmultiple individuals within an organization. With some embodiments ofthis system, the user never has knowledge of their credentials andtherefore cannot share them and furthermore allows the password to bemuch more complicated than a human would create, and also allows thepassword to be changed much more frequently than a human would tolerate.

Web-based authentication: In some embodiments, a centralized loginserver is used to authenticate users to web-based applications. Theuser's machine may have the same outbound IP Address as the centralizedlogin server (in WAN environments, VPNs may be used to satisfy thisrequirement).

When a login request is generated by the user, in some embodiments, thecurrent browser settings, including user-agent, current cookies for therequested domain, and other related browser characteristics, may be sentto the centralized login server. The centralized login server may thencreate a software browser and load the user settings so that thesoftware browser mimics the user's browser. The software browser on thecentralized login server may then attempt to access the homepage of therequested domain. If the user is already authenticated to the site, thecentralized login server returns with the updated cookie settings to theclient machine, where the cookies are automatically placed into thebrowser and the homepage for the domain is loaded into the browser,thereby logging the user in. In some cases, the administrators of thesystem may request a log out and re-login if the user is alreadyauthenticated to the web site for additional security.

If the software browser on the centralized login server detects the useris not authenticated to the domain, in some embodiments, the softwarebrowser looks up the user's credentials in the decentralized scatterpassword archive, navigates to the login screen using JavaScript orother browser interfaces, and inputs the login credentials to thedomain's login screen.

If the domain requires additional login steps (e.g., two-factorauthentication, or a captcha), in some embodiments, the centralizedlogin server passes this information back to the client's machine via asocket established to the client's browser and requests the user tocomplete the action on behalf of the centralized login server. Theuser's completed additional login step, in some embodiments, is thensent back to the centralized login server via the socket from the user'sbrowser, which then allows the centralized login server software browserto input those same user settings into the domain's additional loginstep page.

If there is no additional login step, or the user has completed theadditional login steps, in some embodiments, the software browser on thecentralized login server waits for the homepage to load, then returnsthe newly generated cookies back to the client's machine where they areloaded into the client's browser and the homepage for that domain isloaded as well. The user is now logged into that web application.

Many existing password managers expose the password to the user or breakTLS encryption (e.g., with a universal self-signed certificate authoritypermitting man-in-the middle packet inspection and manipulation). Thesesystems increase the attack surface, either through the human user orthrough exploitation of the universal self-signed certificate authority.In contrast, some embodiments (but not necessarily all embodiments)insert the user credentials at a remote computing device (e.g., thecentralized server), without exposing the credentials to the user, andwithout breaking TLS encryption.

This, in some embodiments, is achieved while supporting features ofmodern browsers, e.g., cookies and other client-side storage. In manycases, the centralized server executes a session-specific instance of ashadow web browser (e.g., the Selenium browser) operation to executeJavaScript™ so as to construct web pages formed dynamically client side.In many cases, the web content (e.g., HTML, CSS, and JavaScript™) sentto the client passes through this server-side browser, and the contentis rendered in two places, on the client and at the server. Thedifference being that the server may insert the credentials in theversion executing server side and submit those credentials. HTTPtransmissions may be modified server-side to spoof those coming from theclient device. Thus, two instances of a browser may render the webpage(one on the intermediate centralized server and one on the clientdevice), the instance on the server may insert the credentials, and theoperation may be transparent to the remote host of the content, avoidingthe need to re-design the traditional client-server architecture uponwhich most of the web is built.

In some embodiments, the centralized server and the client device existon a secure private network, and information sent therebetween may beindependently encrypted, e.g., with another form of encryption that isreapplied, such as via a virtual private network or another TLS or SSLsession operated in parallel with that of the destination serverintermediary server.

Native application authentication: In the case of native applications,in some embodiments, a helper application with a GUI component(tray/menu icon) can be used to request login credentials from thecentralized login server's decentralized (or scattered) password archivefor a specific application when prompted for a login. These credentials,in some embodiments, are then stored in a protected/sandboxed area inmemory and human input (keyboard/mouse) is blocked from the user. Thehelper application, in some embodiments, will then locate theappropriate login window, identify relevant fields (username/password),and mimic keystrokes to appropriately complete and submit the inputs.Lastly, in some embodiments, human input is unblocked from the user andat this time the user is authenticated to the application.

In some embodiments, credentials may be stored by the centralized serverby scattering the data among multiple blockchains, and some embodimentsmay store a resultant TXID (or unique identifier of a record in the moresecure data store) in its place in a relational database (or otherconventional, less secure database). In some cases, the blockchains arepermissioned blockchains, which in some cases, may not implementproof-of-work on participating nodes, or some embodiments may benon-permissioned blockchains.

FIG. 2 shows an example of a process 80 by which some of thesetechniques may be implemented. In some embodiments, the process 80 maybe implemented by the above-described intermediary server 26 of FIG. 1,though embodiments not limited to that implementation, which is not tosuggest that any other description is limiting. In some embodiments, thefunctionality of the process 80 and the other processes andfunctionality described herein, may be implemented with tangible,non-transitory, machine-readable media storing instructions that whenexecuted by one or more processors effectuate the operations describedby those instructions. In some embodiments, notwithstanding the use ofthe singular to “media,” that media may be distributed, with differentsubsets of the instructions stored in memory of different computingdevices that execute those different instructions to collectively giveeffect to the operations described. This arrangement is within the scopeof the singular term “medium.” In some embodiments, the operations ofthe process 80 and the other processes described herein may be executedin different order, operations may be omitted, operations may berepeated, operations may be performed concurrently, and the additionaloperations may be inserted, none of which is to suggest that any otherdescription herein is limiting.

In some embodiments, the process 80 includes intercepting a request toaccess content on a third-party server from a client web browser, asindicated by block 82. In some embodiments, a client web browser may beconfigured with a hosts file or a custom domain name service to sendrequests to an intermediary server, rather than directly to athird-party web server corresponding to a URI to which the request issent, such as a URI of one of the destination server 16 described abovewith reference to FIG. 1. Or in some cases, the intermediary server mayoperate as a gateway and may intercept domain name service requests andsend responses that identify itself as the appropriate computationalentity to communicate with to access resources for the third-partyserver for the client web browser. In some embodiments, the client webbrowser may execute on one of the above-described client computingdevices 14. In some embodiments, the intercepted request may be arequest sent directly to the intermediary server and the interceptionmay be a conceptual interception, rather than requiring that a messageaddressed to some other computational entity be snooped or blocked orotherwise would have made it to the third party server. Thus, in someembodiments, an intermediary server may receive a request to accesscontent on the third-party server, even though the intermediary a serveris not the third-party server itself.

In some embodiments, the access request is a request for content bywhich a user interface to a network-accessible application isconstructed within a web browser, for example, to access resources, suchas a web application, hosted by the third-party server. In someembodiments, the access request is to a different server from thatcontrolled by the third-party, for example an access request to an OAuthauthentication server.

Next, some embodiments may log the access request in the tamper-evident,immutable data store, as indicated by block 84, such as the data storedescribed above. In some cases, log entries may identify a user account,time, geolocation, Internet Protocol address, MAC address, and content,of access requests, for example, or other information pertaining to theclient computing device 14 from which the request was received.

Next, some embodiments may determine whether the client web browser iscurrently authenticated to access the content. In some embodiments, thismay include parsing an access token, or other value demonstratingpossession of the access token, from a parameter of the request, as theclient web browser, in some cases, may append such a value to requeststo demonstrate that the request is authenticated. Or in some cases, theauthentication determine may include accessing a corresponding accesstoken in memory of the above-described headless browser 52 describedwith reference to FIG. 1, for instance, by querying a state of a cookieat an address, for example, having a key, designated by a record in thenetwork-accessible application repository 46 of FIG. 1 that identifieswhere access tokens are stored in browser memory by the third-partyserver issue. Or the assessment may be based on detecting thethird-party server sending a form by which a user logs in.

Upon determining that the client web browser is currently authenticated,for example, upon detecting such an access token in one of theafore-mentioned locations or value indicative thereof, some embodimentsmay proceed to exchange messages between the web browser and thethird-party server until de-authenticated, as indicated by block 96, orthe session is otherwise terminated. In some embodiments, this mayinclude the above-described intermediary server decapsulatingapplication-layer messages from encapsulation in lower-levels of aprotocol stack, for example, decapsulating and reassemblingapplication-layer messages from transport protocol, Internet Protocol,and physical-layer protocol packets or frames, reassembling theapplication-layer messages, and then modifying those application-layermessages (which may include forming new versions thereof that aredifferent in some sense). In some embodiments, modifying thoseapplication higher than layer messages includes modifying hypertexttransport protocol messages. Modifying these messages may includecreating a new version of the message or overriding values in a receivedcopy of a message. In some cases, the modification includes modifyingfields in an application-layer header by which an origin host isidentified to identify the intermediary server 26 instead of the clientcomputing device 14 (as described with reference to FIG. 1) to thethird-party server as the source of the request, rather than the clientcomputing device 14. In some embodiments, the modified message may bere-encapsulated in the lower-layer protocols, identifying an InternetProtocol address and port number of the intermediary server 26 andheadless browser 52 as a source address in some of these lower-layerprotocol headers, before the modified application-layer message istransmitted as encapsulated in a resulting nested arrangement of packetsand frames.

In some embodiments, exchanging messages between the web browser andthird-party server may include reversing the above-described operation,by which application-layer messages, such as hypertext transportprotocol request are encapsulated, assembled, modified, re-encapsulated,and sent, in the other direction, from the third-party server to theclient-computing device. In this direction, the operations may bereversed such that the client-computing device perceives theintermediary server as the host of origin, rather than the third-partyserver. In some embodiments, the application-layer protocol with whichmessages are received may be different from the application-layerprotocol with which messages are transmitted by the intermediary server.For example, in some cases, application-layer messages may be receivedfrom the client application in hypertext transport protocol, and thosemessages may be sent from the intermediary server to the third-partyserver in the HTTPs protocol, for example, according to a TLS or SSLencryption session established with the third-party server and theintermediary server, but not the client computing device. This switch inapplication-layer protocols may be reversed in the opposite direction.In some embodiments, the origin protocol field in application-layerheaders may further be modified by the intermediary server to change theapplication protocol to identify the application-layer protocol withwhich the message is sent, forming another modification toapplication-layer protocol headers performed by the intermediary serverin some cases.

In some embodiments, this exchange may continue until de-authenticationoccurs or a user terminates a session. In some embodiments,de-authentication may occur because an access token times out. In someembodiments, access tokens may be associated with a value that indicateswhen they expire, and the third-party server may cease honoring theaccess token upon that time lapsing. In other cases, the access tokenmay be de-authenticated in a manner that is outside the control of theclient web browser and the third-party server, for example, withoperations described below with reference to FIG. 4.

Some embodiments, alternatively, may determine that the client webbrowser is not authenticated in the operation of block 86. In thisevent, some embodiments may proceed to retrieve an access credentialfrom a tamper-evident, immutable data store, as indicated by block 88.In some embodiments, this may include accessing an access credential,such as a password or encryption key for a password, or encryptedciphertext of a password, that has been segmented and distributed amongmultiple block chains, for example, in accordance with a data structurelike that described below with reference to FIG. 7.

In some embodiments, the process 80 may include submitting a value bywhich possession of an access credential is demonstrated, as indicatedby block 90. In some embodiments, this may include obtaining a userinterface at an intermediary server from the third-party serverconfigured to accept user login credentials. Or some embodiments mayencode in the network-accessible application repository 46 a template bywhich an application program interface request is sent to thethird-party server with a value by which possession of the accesscredential is demonstrated, for example, in a RESTful interface with thevalue encoded as a query string key-value pair in association withanother query string key-value pair that identifies a user account. Insome embodiments, the value by which possession of the access credentialis demonstrated is a password. In some embodiments, the value is acryptographic hash of a password. In some embodiments, the accesscredential is a private key associated with a public key in anasymmetric encryption protocol, and some embodiments may send anidentifier by which the public key may be identified in association witha digital signature based on the private key, such that a receivingthird-party server may verify that the digital signature was signed by aparty with access to the private key associated with a public keyassociated with the signature.

Some embodiments may then receive instructions to store in web browsermemory an access token, as indicated by block 92. In some cases, theinstructions may be JavaScript™ or WebAssembly instructions executableby a web browser, for example, sent as part of web content by which auser interface is to be rendered by a client web browser. In someembodiments, the instructions include a command to write a cookie, storean access token in a localStorage object, or store an access token in aSQLite database of a web browser or other form of browser memory subjectto the same-origin policy. In some embodiments, the command may be acommand to store the access token in persistent browser memory, i.e., atype of browser memory that supports persistent access between browsersessions, for example, after a browser is closed on the client computingdevice and then reopened.

Some embodiments may then send the client web browser instructions tostore the access token in browser memory, as indicated by block 94. Insome embodiments, this operation may include executing the receivedinstructions with a headless browser operated by the intermediaryserver, such that the access token is stored in browser memory of theintermediary server and causing the client web browser to execute thesame instructions, such that web browser state is mirrored, at least inpart both in the headless browser and in the web browser at the clientcomputing device. In some embodiments, a subset of browser state, suchas a subset of persistent browser state, or a subset of browser stateincluding a document object model or virtual document object model, maybe mirrored at both the client web browser to which messages areexchanged and at the headless browser, such that the headless browsermay locally have access to the same information that is available at theclient computing device in some cases.

In some embodiments, the process may proceed to block 96, and the accesstoken stored in browser memory may be used to exchange messages betweenthe web browser executing at the client computing device and thethird-party server until de-authenticated. In some embodiments, thesemessages may be exchanged through the intermediary server describedabove, or in some cases, the messages may bypass the intermediary serverother than when the client computing device is seeking to beauthenticated, for instance, with some subsequent content from thethird-party server being embedded in an i-frame in the client webbrowser controlled by the domain of the third-party server.

In some embodiments, the process of FIG. 2 may log a user into athird-party web service or other remote computing resource without theuser or the user's computing device having access to the authenticationcredential or in some cases the value by which possession of theauthentication credential is demonstrated. As a result, attempts toattack a network by compromising a user's computer with a keylogger andcapturing a password or bribing an employee to reveal their password orspearfishing an employee with an attack that causes them to reveal theirpassword may be ineffective in many cases, as in some embodiments, theuser does not know their password and could not reveal it even if theywanted to. Further, some embodiments may be operative to afford thesebenefits without requiring that an agent be installed on the usercomputing device, as in some many cases, users access sensitiveresources with computing devices that are not necessarily under thecontrol of an IT department. And some embodiments may afford thesebenefits without requiring expensive re-writes of third party webapplications to create other channels of control.

That said, embodiments implementing other techniques described hereinmay perform a traditional login operation at the client computingdevice, in and some cases though, continuing to route messages via theintermediary server, such that an ongoing session may bede-authenticated without waiting for an access token to expire, inaccordance with the techniques described below with reference to FIG. 4.

FIG. 3 shows an example of a process by which native applications may beaccessed while withholding access credentials from users. In someembodiments, some user computing devices may execute native applicationsthat are configured to require an access credential to operate thenative application. In some cases, this may include attempting to accessa file with that native application that requires the access credential,even though other files may be accessed with the same native applicationwithout the access credential.

In some embodiments, some operations of the process 98 may be executedby an agent on a client computing device, and some may be executed bypermission management system, such as those described above withreference to FIG. 1, though embodiments are not limited to thatimplementation, which is not to suggest that any other descriptionherein is limiting.

In some embodiments, the process 98 includes launching an agent, asindicated by block 100. In some cases, the agent may be launchedautomatically in the course of booting an operating system and may runin the background, for example, establishing a TCP connection to anetwork socket of the operating system of the client computing deviceand sending a message to the permission-management system thatidentifies the agent, the client computing device, and in some cases auser identifier of a user using the client computing device. In somecases, this message may include a port number and Internet Protocoladdress by which the permission-management system may send messages tothe agent, which may persistently monitor the network socket.

Some embodiments may then receive a request to launch a nativeapplication, as indicated by block 102. In some embodiments, the agentmay register with the operating system to receive events, for example,emitted by a filesystem driver, that indicate that files, such asexecutables or documents, are being accessed to identify those files ordocuments. These events may be the received request in some embodiments.Or in some cases, the native applications may include code that causesthem to send a request to the agent for permission to launch.

Next, some embodiments may log the access request, as indicated by block104, for example, in the above-described tamper-evident, immutable datarepository. In some cases, the log entry may be sent over a network bythe agent and may identify a user, a time, a geolocation, andapplication being accessed, a file being accessed, and other parameterspertaining to the request to launch the native application. In someembodiments, subsequent interactions with a native application maysimilarly be logged, for example, logging events in which files arewritten or in which files are opened.

Next, some embodiments may obtain an access credential from securestorage, as indicated by block 106. In some cases, the agent mayretrieve the access credential from the above-describe tamper-evident,immutable data repository, though this approach may present problems forsome users who require off-line access. In these scenarios, someembodiments may store the access credential for the native applicationon the client computing device in secure storage, for example in asecure sandbox (and such storage may be used when credentials aretemporarily held). Some embodiments may encrypt the access credential ina ciphertext with an encryption key stored in or protected by encryptionbased on value stored in a secure element of the client computing devicein some embodiments.

Some embodiments may attempt to authenticate the launch of the nativeapplication on behalf of the user associated with the access credentialand determine whether the operation is successful, as indicated by block108. Upon determining that the access credential is not valid, someembodiments may block the native application from launching, asindicated by block 110. In some cases, this may include logging thefailed request in accordance with the operations of block 104, forexample, including a logged event indicating that the request failed.Some embodiments may further present a user interface message indicatinga reason why the application failed to launch.

Alternatively, upon successfully authenticating, some embodiments mayproceed to execute the native application, as indicated by block 112.Some embodiments may then monitor for a de-authentication command, asindicated by block 114, and continue to execute the native applicationuntil such a de-authentication command is received or a user closes thenative application. In some embodiments, access credentials may beassociated with an expiration time, and some embodiments may check theoperating native application against the expiration time and terminatethe native application upon that time being exceeded and require networkaccess to issue a new locally-stored authentication credential after theexpiration time, for example, from the permission-management system.

In some embodiments, a de-authentication command may be received fromthe permission management system, for example, following operationsdescribed below. Some embodiments may then terminate the nativeapplication, as indicated by block 116 and remove the access credentialfrom secure storage, as indicated by block 118. In some embodiments, theaccess credential may be removed by deleting a value or by overridingthe value. Or in some cases, the access credential may be automaticallydeleted upon authenticating.

In some embodiments, the permission-management system, such as thepermission-management system described above with reference to FIG. 1,may receive requests for a user interface from an administratorcomputing device, as indicated by block 120. In some cases, this may bea request for a web-based user interface, like that described below withreference to FIG. 6.

Some embodiments may then send the user interface to the administratorcomputing device, as indicated by block 122, and then later receive arequest to manage permissions, as indicated by block 124. Someembodiments may determine whether it is a request to de-authenticate, asindicated by block 126. If the request is a request to de-authenticatethe native application executing on the client computing device, someembodiments may proceed to block 128 and send a de-authenticationcommand that engages the functionality following an affirmativedetermination at block 114 on the client computing device. In somecases, the de-authentication command may be sent to the network socketidentified to the permission management system upon launching of theagent in block 100.

Some embodiments may further log the de-authentication in thetamper-evident immutable data store, as indicated by block 130, andupdate permissions in the tamper-evident immutable data store, asindicated by block 132, for example, indicating that the correspondinguser does not have permission to access the corresponding nativeapplication for which a de-authentication command was received.

Alternatively, upon determining that the request to manage permissionsdoes not pertain to de-authentication, some embodiments may engage otherfunctionality described below with reference to FIG. 5 and then returnto block 120 to wait for the next request for a user interface from theadministrator computing device.

Remotely Deauthenticating a User from a Web-Based Application Using aCentralized Login Server

Some SaaS applications permit an administrator to adjust a user'scredentials, e.g., canceling or changing permissions associatedtherewith. But in many cases, those systems do not terminate an ongoingsession with the user. For instance, a user may remain logged in afterbeing terminated for several hours, potentially leaking information orengaging in other malicious activity. To mitigate this, some existingsystems force the user to log-out periodically, but such systems imposea high cognitive burden on users and interrupt legitimate sessions withthe repeated request to re-authorize access.

Remotely deauthenticating a user from a web-based application using acentralized login server: As noted, administrative tools exist to changea user's password or disable a user account within web-basedapplications (or native application sessions). However, it is also thecase that by changing the password, the user's current session mayremain active until they explicitly log out or their authenticationtoken expires (generally stored in cookies).

To mitigate these and other problems, some embodiments use continuouslyopen connections from a user's browser to a centralized login server tocommand the client's browser to delete all cookies (authenticationtokens) for a specific web domain. Also, in some embodiments, byexecuting this command, the client's browser will close all browser tabsand windows that are currently utilizing the specific web domain forwhich authentication privileges have been removed.

Many other centralized login systems (CASBs) lack the connectivity tothe client's specific session to be able to exercise this level ofcontrol.

In some cases, this technique may be performed with a dual-browserapproach like that described above. In some embodiments, thearchitecture is also used to prevent the user from accessing their logoncredentials, but not all embodiments afford this benefit (e.g., the usermay access and enter their credentials, while the present techniques areused to terminate access selectively).

Some embodiments include a system designed to be used by businessemployees where they are required to access web-based or nativeapplications where credentials might otherwise need to be shared amongstmultiple individuals within an organization. With some embodiments ofthis system, the user never has knowledge of their credentials andtherefore cannot share them and furthermore allows the password to bemuch more complicated than a human would create, e.g., a random stringlonger than 32 bytes.

FIG. 4 shows an example of a process 134 by which theabove-functionality may be implemented. In some embodiments, theoperations of the process 134 may be executed by the intermediary serverdescribed above with reference to FIG. 1, though embodiments are notlimited to that implementation, which is not to suggest that any otherdescription herein is limiting.

In some embodiments, the process 134 includes relaying application-layermessages between a client web browser and a destination server to obtainsame-origin privileges on the client-web browser for content sent by thedestination server, as indicated by block 136. In some cases, relayingapplication-layer messages may include modifying values in headers thatidentify an origin host by the intermediary server, such that both theclient web browser and the destination server perceive the intermediaryserver as the remote computing device with which they are communicating.

Some embodiments may include inserting code in in-bound messages thatopens a continuous connection from the web browser on the clientcomputing device, as indicated by block 138. In some embodiments, thismay include inserting a JavaScript or WebAssembly routine that, whenexecuted by a client web browser, establishes a websocket connectionbetween a webpage on the client computing device and the intermediaryserver, such that the client computing device can receive messages fromthe intermediary server in real time, without waiting for the clientcomputing device to pull the intermediary server. Or in someembodiments, such inserted code may cause the client computing device toperiodically poll the intermediary server for control messages, such asde-authentication commands.

Some embodiments may then determine whether to de-authenticate anongoing authenticated session between the client web browser and thedestination server, as indicated by block 140. Upon determining not tode-authenticate, some embodiments may return to block 136 and continuerelaying application-layer messages and inserting code is needed tomaintain connections.

Alternatively, upon determining to de-authenticate, for example, inresponse to receiving a de-authentication command via the process ofFIG. 5, some embodiments may send instructions that cause the client webbrowser to delete or modify an access token stored in memory of theclient web browser by the destination server, as indicated by block 142.In cases in which an agent is installed on the client computing device,some embodiments may further send instructions to the agent that causesthe agent to close a client web browser tab or client web browserinstance. In some embodiments, the sent instructions may be sent via anopen websocket connection. In some embodiments, the inserted code inblock 138 may be formed based on application-specific records thatindicate addresses in web browser memory where authentication tokens arestored, and the inserted code in some cases may include code that,responsive to the sent instructions, deletes or otherwise overwrites orrenders in operative the stored authentication token at the identifiedaddress, such as in an identified cookie, localStorage object, or SQLitedatabase entry.

Some embodiments may then log the de-authentication in thetamper-evident, immutable data store, as indicated by block 144, andupdate permissions in the tamper-evident immutable data store, asindicated by block 146.

Thus, some embodiments executing the process 134 may terminate an activesession in which a user is having an authenticated authorized exchangewith a third-party destination server, without waiting for anauthentication token to expire, and in some cases without requiring anagent be installed on the client computing device

Centralized Access Management of Web-Based or Native

To manage user access, organizations often employ permissioning systems.However, such systems are often very complex and require specifictraining on their operation. Additionally, these permissioning systemsare often disparate, with no centralized location for management.Finally, changes to a user's or user group's permissions are often notrecorded in a centralized, persistent, immutable data store, which couldlend itself to tampering or other misuse. (None of which is to suggestthat systems exhibiting various subsets of these problems aredisclaimed, or that any other subject matter is disclaimed.) In somecases, permission management may extend upon related techniquesdescribed in U.S. patent application Ser. No. 15/171,347, titledCOMPUTER SECURITY AND USAGE-ANALYSIS SYSTEM, the contents of which areincorporated by reference.

FIG. 5 shows an example of a process 148 by which the above-describedand other techniques may be implemented. In some embodiments, theprocess 148 may be executed by the above-described permission-managementapplication to provide a centralized login management service that isoperative to control both native applications (e.g., thick clientapplications, or monolithic non-networked applications) and hostedapplications access with a thin client by user computing devices.Further, and some cases the process 148 may cause access events andupdates to permissions to be logged in various tamper-evident, immutabledata stores that tend to deter threat actors from engaging in maliciousmanipulation of access credentials due to near certainty of beingdiscovered.

In some embodiments, the process 148 may include receiving a request fora user interface from the administrator computing device, as indicatedby block 150, for example, a request for web content from a usercomputing device web browser. Some embodiments may respond by sending auser interface to the administrator computing device 152, for instance,by sending a user interface like that described below with reference toFIG. 6. Some embodiments may then receive a current request to managepermissions, as indicated by block 154, from the administrator computingdevice, for instance, upon a user clicking on, touching, dragging anddropping, or otherwise selecting various inputs in the user interfaceassociated with corresponding event handlers in program code of the sentuser interface that cause the client computing device to send therequest that specifies how to permissions are to be managed.

Some embodiments may determine whether the request is a request toremove a permission, as indicated by block 154, such as a request toremove a permission for a particular type of application for aparticular group of users or users in a particular role, which in somecases may be specified by the request and, in some cases, may correspondto records in the above-described repositories. Upon determining thatthe request is a request to remove a permission, some embodiments maydetermine an application type associated with the request as indicatedin block 158. Upon determining that the application type is anetwork-accessible application, such as a SaaS application hosted by athird party and accessed with a thin client, such as a web browser, onuser computing devices, some embodiments may proceed to block 160. Someembodiments may then select an application program interface translationtemplate, for instance, in accordance with the techniques describedabove, and translate an application program interface request based onthe translation template, as indicated by block 162. In someembodiments, the received request to manage permission may be in aunified schema specifying a unified format by which an administercomputing device may communicate requests to manage permissions that areeffective to manage a heterogeneous mix of native applications andnetwork accessible applications each having different applicationprogram interfaces. The translation operational block 162 may includeidentifying fields in the template where values specified in the requestare to be inserted, and inserting those values to form a validapplication program interface request to the network-accessibleapplication specified in the requite class to manage permissions.

Some embodiments may then send the instructions to remove permissions,as indicated by block 164, for instance, sending the application programinterface request to a third-party web server using the translatedapplication program interface request, e.g., to a destination server 16described with reference to FIG. 1. Some embodiments may further engagethe process of FIG. 4 above to terminate a current session between anidentified user computing device are identified user and thenetwork-accessible application identified in the request to managepermissions, as indicated by block 166. Some embodiments may also engagethe process of FIG. 3 to close a web browser instance.

In some embodiments, this, and each of the other changes to permissionsdescribed herein, may be logged as an event in a tamper-evident,immutable data store, as indicated by block 168, and some embodimentsmay update permissions in the tamper-evident, immutable data store, asindicated by block 170 to reflect the request to manage permissions. Insome embodiments, the updated permission may serve as the authoritativerecord of permissions granted to a user.

The term “immutable” in the phrase “immutable data structure” refers toan arrangement of data that the computing system and write the rightcommand is configured to leave in place even after the informationrepresented by the data changes. For example, the data might represent auser's telephone number, and embodiments using an immutable datastructure may write a new record indicating a new telephone number,rather than overwrite an existing record. Thus, both the older versionand the newer version are preserved (and may be labeled as the older ornewer version) even after the value changes. Such embodiments may thenreference a most recent representation of the value for that field toeffectuate the change, rather than deleting the old instance.

In some embodiments, the immutable data structure may be atamper-evident data structure that is computationally infeasible tomodify without the modification being detectable to a party auditing thedata structure. Some embodiments may implement cryptographic hashpointers described below in a directed acyclic graph that make itcomputationally infeasible for a party to modify stored data withoutthose modifications being evident in virtue of inconsistent hash valueselsewhere in the data structure. Computational feasibility may depend onthe use case, for example, whether economics and time available providefor certain amounts of competing resources to be brought to bear. Inmany cases, an operation requiring more than 10{circumflex over ( )}128hashes on average to manufacture a collision with altered data may besaid to be computationally infeasible.

Some embodiments may then return to block 150 and wait for the nextrequest for a user interface.

Alternatively, in block 158, upon determining that the application typeis a native application, some embodiments may proceed to identify anetwork address of the agent, indicated by block 172, of the computingdevice in which a specified instance of the native applicationcorresponding to the request to manage permissions is configured toexecute, for instance, where the executable is stored. Some embodimentsmay then send instructions to the agent to terminate the nativeapplication session and local credentials if present, as indicated byblock 174. In some embodiments, these operations may include theoperations described above with reference to FIG. 3. In some cases, theclient computing device at issue may be off-line, and embodiments maymaintain an inventory of tasks that is interrogated upon being contactedby an agent. Upon detecting a task corresponding to the agent,embodiments may then send a message that instructs the agent to take thespecified action.

Some embodiments may then proceed to log the event and updatepermissions, as indicated by block 168 and 170 and described above,before returning the block 150.

Alternatively, upon determining in block 156 that the request does notpertain to removing permissions, some embodiments may proceed to block176, and determine whether the request pertains to granting permissions.Upon determining that the request does not pertain to grantingpermissions, some embodiments may address other operation specified inthe request, or send a user interface to the administrator computingdevice indicating an invalid request and presenting an opportunity forthe user to submit a modified request manage permissions.

Alternatively, upon determining that the request is to grantpermissions, some embodiments may proceed to determine an applicationtype of the request, as indicated by block 178. Upon determining thatthe application type is a network-accessible application, someembodiments may proceed to block 184 and select an application programinterface translation template. In some cases, this may includeoperations like those described above with reference to block 160 andmay be followed by translating an incoming unified application programinterface request into an application-program interface request inaccordance with the schema of the network-accessible application, asindicated by block 186, for example, applying techniques like thosedescribed above with reference to block 162. Next, some embodiments maysend instructions to a destination server implementing thenetwork-accessible application, or controlling access for thenetwork-accessible application, and those instructions may cause thenetwork-accessible application to update a user account to grant thepermission, as indicated by block 188.

Some embodiments may then proceed to log the event and updatepermissions, as indicated by block 168 and 170 and described above,before returning the block 150.

Alternatively, in block 178, upon determining that the application typeis a native application, some embodiments may identify a network addressof an agent associated with a user for whom permission is to be grantedfor a network at a native application, as indicated by block 180. Someembodiments may then send instructions to the agent to securely storecredentials to facilitate off-line access in the secure local storage,as described above, as indicated by block 182. Or in some cases, thecredentials may be stored exclusively remotely from the client computingdevice, for example in the tamper-evident, immutable data store.

Some embodiments may then proceed to log the event and updatepermissions, as indicated by block 168 and 170 and described above,before returning the block 150.

Thus, some embodiments may provide a unified interface by which aheterogeneous set of native applications and a heterogeneous set ofnetwork-accessible applications exposing various different applicationprogram interface schemas, may be managed, for instance, via a unifieduser interface by which requests to manage permissions are input,formed, and sent. Further, embodiments may log corresponding events andpermissions in tamper-evident, immutable data stores, such asblockchains, in some cases like those described below with reference toFIG. 7, thereby determining threat actors from attempting to compromisethese records.

FIG. 6 shows an example of a drag-and-drop user interface 110 by whichusers may enter request to manage permissions. The user interface ofFIG. 6 may be that sent in the operation of block 152, and may send therequest received in operation in block 154. In some embodiments, acolumn of circular icons 112 may each represent a different cloudservices web application, circular icons in columns 114 may eachrepresent users, and a set of columns of circular icons 116 may eachrepresent computing devices or groups thereof. Some embodiments mayfurther support icons representing groups of users. Permissions may bemodified by adding, deleting, or changing attributes of edges 118indicating respective pairs of these entities to which permissionsdefined apply.

FIG. 7 shows an example of a resulting data structure 230 in which aplurality of segments are stored in different directed acyclic graphs232, 234, and 236, which in some cases may each have the features of thedirected acyclic graphs described with reference to FIG. 3 in the patentapplication titled IMMUTABLE DATASTORE FOR LOW-LATENCY READING ANDWRITING OF LARGE DATA SETS, filed on the same day as this application,the contents of which are hereby incorporated by reference. In someembodiments, credentials, log entries, and records mapping permissionsto users may be segmented, and the segments of a given value may bestored in a content graph overlaid on each of these directed acyclicgraphs 232, 234, and 326, which may be characterized as a verificationgraphs to distinguish an overlaid content graph (and as they serve as animmutable tamper-evident log of the values of the segments in someembodiments).

In this example, the segments in the content graph 238 form a linkedlist, with a first node of the segment content graph 238 being stored ina leaf node 239 of verification graph 232, that first segment beingdesignated as node 240 in the content graph. The node 240 in the contentgraph may be stored as an attribute in node content in the node 238 ofthe verification graph, and the content node 240 may include a pointer242 to a next node in the content graph 238, which may be stored on adifferent verification graph 234. In some cases, the pointer 242 may becharacterized as an edge in the content graph 238 and may be expressedas an identifier of a node 243 in the verification graph 234 or in somecases as an identifier of an attribute in that node where multiplesegments are stored in different attributes of a given node of averification graph. In some embodiments, in the content graph 238, node240 points to another segment 244, which may then the point to anothersegment with pointer 246 in verification node 247 of verification graph236. Verification node 247 may include as node content one or moreattributes that specify a final segment in content graph 238 designatedwith element number 248. In some cases, node 148 may specify that thereare no additional nodes in the value.

As a result, even if a given malicious actor somehow compromises one ofthe verification graphs 232, 234, or 236, that attacker will only beable to access a set of segments of values and will not have access toother segments needed to complete the full value. Further, because thesegments are stored in a tamper-evident directed acyclic graph with theabove-described hash point cryptographic hash pointers serving asedges/pointers, evidence of tampering will not be computationallyfeasible to conceal.

Thus, FIG. 7 shows a plurality of verification directed acyclic graphs232, 234, and 236, each of which may be replicated, and each of whichhas nodes that may store as node content data that encodes a contentgraph 238, which in this case is a linked list of segments, where eachsegment in sequence points to the next segment and its correspondingaddress, and in some cases attribute identifier in the underlyingverification graphs.

In this example, segments are arranged in a one-dimensional linked list,but embodiments are consistent with other arrangements of contentgraphs. For example, some segments may include pointers to multiplesubsequent segments, for example, in a skip list to facilitateconcurrent retrieval, and in some cases segments may be stored inassociation with a segment position identifier, for example, an order inwhich the segments are to be sequenced to reconstitute the segmentedvalue in a read operation. In another example, segments in a contentgraph encoding a plurality of segments of an individual value may bestored in a binary tree content graph, a skip list content graph, or acombination of binary trees, linked lists, skip lists, and the like.

Three segments for a given value are shown, but embodiments are expectedto include substantially more in some cases. In some cases, binary dataencoding a single text character may be segmented, for example with agiven Unicode character being segmented into two or more segments, and agiven value yielding 10 or more or 20 or more segments, which in somecases may each be stored in different distributed acyclic graphs, whichin some cases may each be replicated multiple times, for example 3 ormore times. Thus, a given value may be stored in part on 30 differentstorage compute nodes. In some cases, different instances may becompared to determine an authoritative copy, e.g., selecting a storedand returned value according to a majority rule approach among thereplicated instances. In some cases, e.g., where the replicatedinstances of the graphs are on permissioned computing devices,embodiments may vote for a given value without performing a proof ofwork or proof of storage operation, or where devices storing the graphsare untrusted, some embodiments may determine consensus with a proof ofwork, storage, or stake, e.g., according to a consensus protocol, likePaxos, Raft, or the like. In some embodiments, e.g., in untrustedsystems, instances may be addressed according to Interplanetary FileSystem (IPFS) or with various distributed hash table approaches.

In the example of FIG. 7, each of the directed acyclic graphs 232, 234,and 236 is the same type of directed acyclic graph, in this case alinked list of binary trees, where edges are formed by cryptographichash pointers. In other embodiments, a heterogeneous set of directedacyclic graphs may be combined, for example with different segmentsstored in different types of graphs. For example, an initial segment maybe stored in a binary tree, while other segments may be stored indirected acyclic graphs like those shown in FIG. 7, for example, inlinked lists of binary trees.

Cryptographic hash pointers may be based upon a cryptographic hashfunction which may take a plurality of inputs, such as one or more nodeattributes and produce an output of fixed size. These functions may havepre-image resistance, second pre-image resistance, and collisionresistance. Examples include an SHA-256, BLAKE, BLAKE2, SHA-1, SHA-2,and SHA-3 hash function. In some embodiments, the cryptographic hashfunction may be a one way function in which a given string of inputproduces deterministically a string of output that is relativelydifficult or impossible to reverse to determine the input from theoutput while being relatively easy to confirm that an input correspondsto the output. For example, it may be computationally infeasible toidentify a hash collision in which different instances of the inputproduce a given output. In some embodiments, the cryptographic hashfunction may implement the Merkle-Damgård construction.

In some embodiments, each binary tree in FIG. 7 may be characterized asa block (in a linked list of blocks) with a root node. In someembodiments, each of the arrows between blocks in the binary trees mayalso be cryptographic hash pointers, for example, based on an identifierof the node to which the cryptographic hash pointer points and acryptographic hash value based upon node content of that node, which mayinclude an attribute of that node that is itself a cryptographic hashvalue of another hash pointer. Thus, in some cases, a cryptographic hashvalue of a root node may be based upon node content of every node of thebinary tree. In some embodiments, a root node may include three suchcryptographic hash pointers, corresponding to six node attributes, thesix attributes including three pairs of node identifiers andcryptographic hash values based on node content of those nodes. In someembodiments, node content may further include a cryptographic hash valuebased upon each of these values, or such a cryptographic hash value maybe stored in another node that points to that node. The illustratedgraphs are acyclic. As that term is used herein, it may refer to anacyclic subset of a larger cyclic graph. Thus, claims to acyclicdirected graphs may not be avoided simply by adding an un-used cycle.

In some embodiments, the cryptographic hash function may be based upon acompression function that accepts a fixed size input and produces afixed sized output with a one-way compression function. In someembodiments, because the input to the cryptographic hash function may bea variety of different sizes, the transformation may be performed in avariety of iteration and a plurality of iterations. Some embodiments maydetermine a length of input, such as a number of bytes, accepted by theone-way compression function, a length of output of the one-waycompression function and determine a difference between these twolengths. Some embodiments may then parse an input to the cryptographichash function into sequences of a size of this difference anditeratively input the parsed sequence into the one-way compressionfunction and then combine the output of that iteration with a nextportion parsed portion from the input, for example, incrementing from abeginning to an end of an input and iteratively concatenating, forexample, prepending or appending or otherwise intermingling the outputof the previous iteration of the one-way compression function with anext parsed portion of the input to the cryptographic hash function.Some embodiments may repeat this until an end of the input to thecryptographic hash function is reached (e.g., reaching a point withinsome threshold number of bytes or the last byte). In some embodiments,for example, where a plurality of inputs are applied, some embodimentsmay combine these inputs in a variety of approaches, for exampleprepending or appending or otherwise intermingling these inputs to forma string upon which these operations may be performed to produce a fixedsized output that is based upon the entirety of the input.

FIG. 8 is a diagram that illustrates an exemplary computing system 1000in accordance with embodiments of the present technique. Variousportions of systems and methods described herein, may include or beexecuted on one or more computer systems similar to computing system1000. Further, processes and modules described herein may be executed byone or more processing systems similar to that of computing system 1000.

Computing system 1000 may include one or more processors (e.g.,processors 1010 a-1010 n) coupled to system memory 1020, an input/outputI/O device interface 1030, and a network interface 1040 via aninput/output (I/O) interface 1050. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1000. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1020). Computing system 1000 may be a uni-processor systemincluding one processor (e.g., processor 1010 a), or a multi-processorsystem including any number of suitable processors (e.g., 1010 a-1010n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1000may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1030 may provide an interface for connection of oneor more I/O devices 1060 to computer system 1000. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1060 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1060 may be connected to computer system 1000through a wired or wireless connection. I/O devices 1060 may beconnected to computer system 1000 from a remote location. I/O devices1060 located on remote computer system, for example, may be connected tocomputer system 1000 via a network and network interface 1040.

Network interface 1040 may include a network adapter that provides forconnection of computer system 1000 to a network. Network interface may1040 may facilitate data exchange between computer system 1000 and otherdevices connected to the network. Network interface 1040 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1020 may be configured to store program instructions 1100or data 1110. Program instructions 1100 may be executable by a processor(e.g., one or more of processors 1010 a-1010 n) to implement one or moreembodiments of the present techniques. Instructions 1100 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1020 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or thelike. System memory 1020 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1010 a-1010 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1020) may include asingle memory device and/or a plurality of memory devices (e.g.,distributed memory devices). Instructions or other program code toprovide the functionality described herein may be stored on a tangible,non-transitory computer readable media. In some cases, the entire set ofinstructions may be stored concurrently on the media, or in some cases,different parts of the instructions may be stored on the same media atdifferent times.

I/O interface 1050 may be configured to coordinate I/O traffic betweenprocessors 1010 a-1010 n, system memory 1020, network interface 1040,I/O devices 1060, and/or other peripheral devices. I/O interface 1050may perform protocol, timing, or other data transformations to convertdata signals from one component (e.g., system memory 1020) into a formatsuitable for use by another component (e.g., processors 1010 a-1010 n).I/O interface 1050 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1000 or multiple computer systems1000 configured to host different portions or instances of embodiments.Multiple computer systems 1000 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1000 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1000 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1000 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1000 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1000 may be transmitted to computer system1000 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present techniques may be practiced with othercomputer system configurations.

In block diagrams, illustrated components are depicted as discretefunctional blocks, but embodiments are not limited to systems in whichthe functionality described herein is organized as illustrated. Thefunctionality provided by each of the components may be provided bysoftware or hardware modules that are differently organized than ispresently depicted, for example such software or hardware may beintermingled, conjoined, replicated, broken up, distributed (e.g. withina data center or geographically), or otherwise differently organized.The functionality described herein may be provided by one or moreprocessors of one or more computers executing code stored on a tangible,non-transitory, machine readable medium. In some cases, notwithstandinguse of the singular term “medium,” the instructions may be distributedon different storage devices associated with different computingdevices, for instance, with each computing device having a differentsubset of the instructions, an implementation consistent with usage ofthe singular term “medium” herein. In some cases, third party contentdelivery networks may host some or all of the information conveyed overnetworks, in which case, to the extent information (e.g., content) issaid to be supplied or otherwise provided, the information may providedby sending instructions to retrieve that information from a contentdelivery network.

The reader should appreciate that the present application describesseveral independently useful techniques. Rather than separating thosetechniques into multiple isolated patent applications, applicants havegrouped these techniques into a single document because their relatedsubject matter lends itself to economies in the application process. Butthe distinct advantages and aspects of such techniques should not beconflated. In some cases, embodiments address all of the deficienciesnoted herein, but it should be understood that the techniques areindependently useful, and some embodiments address only a subset of suchproblems or offer other, unmentioned benefits that will be apparent tothose of skill in the art reviewing the present disclosure. Due to costsconstraints, some techniques disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such techniques or all aspects of suchtechniques.

It should be understood that the description and the drawings are notintended to limit the present techniques to the particular formdisclosed, but to the contrary, the intention is to cover allmodifications, equivalents, and alternatives falling within the spiritand scope of the present techniques as defined by the appended claims.Further modifications and alternative embodiments of various aspects ofthe techniques will be apparent to those skilled in the art in view ofthis description. Accordingly, this description and the drawings are tobe construed as illustrative only and are for the purpose of teachingthose skilled in the art the general manner of carrying out the presenttechniques. It is to be understood that the forms of the presenttechniques shown and described herein are to be taken as examples ofembodiments. Elements and materials may be substituted for thoseillustrated and described herein, parts and processes may be reversed oromitted, and certain features of the present techniques may be utilizedindependently, all as would be apparent to one skilled in the art afterhaving the benefit of this description of the present techniques.Changes may be made in the elements described herein without departingfrom the spirit and scope of the present techniques as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless otherwise indicated, statementsthat “each” instance of some collection have some property should not beread to exclude cases where some otherwise identical or similar membersof a larger collection do not have the property, i.e., each does notnecessarily mean each and every. Limitations as to sequence of recitedsteps should not be read into the claims unless explicitly specified,e.g., with explicit language like “after performing X, performing Y,” incontrast to statements that might be improperly argued to imply sequencelimitations, like “performing X on items, performing Y on the X'editems,” used for purposes of making claims more readable rather thanspecifying sequence. Statements referring to “at least Z of A, B, andC,” and the like (e.g., “at least Z of A, B, or C”), refer to at least Zof the listed categories (A, B, and C) and do not require at least Zunits in each category. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.

In this patent, certain U.S. patents, U.S. patent applications, or othermaterials (e.g., articles) have been incorporated by reference. The textof such U.S. patents, U.S. patent applications, and other materials is,however, only incorporated by reference to the extent that no conflictexists between such material and the statements and drawings set forthherein. In the event of such conflict, the text of the present documentgoverns.

The present techniques will be better understood with reference to thefollowing enumerated embodiments:

1. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: receiving, via a first network, with anintermediary server, a request to access web content at a web contentserver, wherein: the request is received from a client web browserexecuting on a client computing device, the client computing devicebeing a different computing device from the intermediary server; atleast some communications between the client web browser and at leastsome remote websites accessed by the client web browser are relayed bythe intermediary server; and the intermediary server comprises anintermediary web browser configured to cooperate with the client webbrowser to form a distributed web browser in which a first subset ofwebpage state of remotely hosted webpages is mirrored on both the clientweb browser and the intermediary server and a second subset of webpagestate of the remotely hosted webpages is formed on the intermediaryserver but not on the client web browser; determining, at theintermediary server, that the user needs to be authenticated beforeaccessing at least some content reachable via the web content server,wherein an access credential by which the user is authenticated isaccessible to the intermediary server but not to the user of the clientcomputing device; submitting, from the intermediary server, to a remoteserver configured to authenticate the user, via a network socket bywhich the intermediary web browser is connected to a second network, avalue by which possession of the access credential is demonstrated,wherein the value is part of the second subset of webpage state and iswithheld from the client web browser; receiving, by the intermediary webbrowser, via the network socket by which the intermediary web browser isconnected to the second network, instructions to store in web browsermemory an access token, poof of possession of which is to be sent withsubsequent messages to one or more severs hosting the at least somecontent to demonstrate the respective message is from an authenticateduser; and sending, from the intermediary server, to the client webbrowser executing on the client computing device, via the first network,instructions to store the access token in browser memory of the clientweb browser, wherein: the instructions cause the client web browser tosend messages with a value that demonstrates possession of the accesstoken, thereby authenticating the client web browser without the clientweb browser having access to the value by which possession of the accesscredential is demonstrated.2. The medium of embodiment 1, wherein: the value by which possession ofthe access credential is demonstrated is the access credential, acryptographic hash value based on the access credential, or a digitalsignature signed with the access credential; the remote serverconfigured to authenticate the user is the web content server, anauthorization server in a OAuth protocol, or an authorization server inan OAuth 2 protocol; the access token is received from the remote serverconfigured to authenticate the user or a different remote server; theweb browser memory is a cookie, a localStorage object, or a web browserSQLite database; and all communications between the client web browserand the web content server are relayed by the intermediary server.3. The medium of any one of embodiments 1-2, wherein: the intermediaryweb browser is a headless web browser configured to render web contentrequested by the client computing device, such that at least some webcontent responsive to a single request is rendered twice, once by theintermediary web browser and once by the client web browser.4. The medium of embodiment 3, wherein: the headless web browser isconfigured to execute JavaScript and WebAssembly by which a documentobject model or virtual document object model is modified.5. The medium of any one of embodiments 1-4, wherein: the value by whichpossession of the access credential is demonstrated is a password to asoftware-as-a-service application that includes the at least somecontent.6. The medium of any one of embodiments 1-5, wherein the operationscomprise: obtaining, at the intermediary server, with the intermediaryweb browser, a login interface for users to enter access credentials toaccess the at least some content; rendering, at the intermediary server,with the intermediary web browser, the interface; programmaticallyidentifying, at the intermediary server, with the intermediary webbrowser, a text box input in a document object model or virtual documentobject model of the interface; programmatically entering, at theintermediary server, with the intermediary web browser, the accesscredential in the identified textbox input of the rendered interface;and programmatically creating, at the intermediary server, with theintermediary web browser, a user-interface event that causes therendered interface to submit the value by which possession of the accesscredential is demonstrated.7. The medium of embodiment 6, wherein the operations comprise:classifying a subset of a document object model or virtual documentobject model of the rendered interface as pertaining to captcha; and inresponse to the classifying, sending web content that renders to form atleast the subset of the document object model or the virtual documentobject model to the client web browser for human input.8. The medium of any one of embodiments 1-7, wherein: the first networkis a virtual private network or a private subnet directly connecting theclient computing device and the intermediary server; and the secondnetwork is the Internet.9. The medium of any one of embodiments 1-8, wherein the operationscomprise: obtaining, at the intermediary server, a browser fingerprintof the client device browser, the browser fingerprint including at leastsome user-agent fields from a user-agent string parsed from anapplication-layer transport protocol message from the client webbrowser; and configuring the intermediary web browser to have at leastsome attributes of the client web browser based on the obtained browserfingerprint.10. The medium of embodiment 9, wherein: configuring the intermediaryweb browser to have at least some attributes comprises configuring theintermediary web browser to have an identical user-agent string to theclient web browser.11. The medium of any one of embodiments 1-10, wherein: the intermediaryweb browser mimics the client web browser for at least a subset ofexchanges with one or more remote servers.12. The medium of any one of embodiments 1-11, wherein: the clientcomputing device is configured to access a private domain name serviceor hosts file that causes the client computing device to send requeststo an Internet Protocol address of the intermediary server rather thanan Internet Protocol address of the web content server; and theintermediary web browser is configured to access a public domain nameservice to advance messages to the Internet Protocol address of the webcontent server.13. The medium of any one of embodiments 1-12, wherein: a third subsetof webpage state is formed in the client web browser but is not mirroredat the intermediary web browser.14. The medium of any one of embodiments 1-13, wherein: transport-layersecurity (TLS) encryption between the intermediary web browser and theweb content server is maintained while mirroring content on the clientweb browser.15. The medium of any one of embodiments 1-14, wherein the operationscomprise: executing a helper application on a client computing devicehaving a native application configured to be authenticated via a remoteserver; and authenticating, with the helper application, the user toaccess the native application with another access credential stored in asandboxed area of memory by submitting the access credential withoutproviding the user access to the other access credential.16. The medium of any one of embodiments 1-15, wherein the operationscomprise: causing the access credential to be segmented onto a pluralityof segments; and causing different subsets of the plurality of segmentsto be stored in different tamper-evident, immutable directed acyclicgraph having edges defined by cryptographic hash pointers based onrespective subsets of the segments.17. The medium of any one of embodiments 1-16, wherein the operationscomprise: logging the access request to a tamper-evident, immutabledirected acyclic graph having edges defined by cryptographic hashpointers based on log entries.18. The medium of any one of embodiments 1-17, wherein the operationscomprise: steps for logging a user into a web-service without an accesscredential being made available to the user's web browser.19. The medium of any one of embodiments 1-18, wherein the operationscomprise: accessing plurality of software-as-a-service enterpriseapplications by authenticating the user to the software-as-a-serviceenterprise applications without the user having access to accesscredentials for the software-as-a-service enterprise applications.20. A method, comprising: the operations of any one of embodiments 1-19.21. A system, comprising: one or more processors; and memory storinginstructions that when executed by the processors cause the processorsto effectuate operations comprising: the operations of any one ofembodiments 1-19.

What is claimed is:
 1. A tangible, non-transitory, machine-readablemedium storing instructions that when executed by one or more processorseffectuate operations comprising: receiving, with one or more processorsexecuting a permission-management application, a first request to managepermissions of one or more users to access resources with clientcomputing devices, wherein: the permission-management application isconfigured to manage permissions for users of an organization to accessa plurality of network-accessible applications; the plurality ofdifferent network-accessible applications have differentpermission-management application program interfaces; and thepermission-management application is configured to manage permissionsfor users to access respective instances of a plurality of differentnative applications executing on the client computing devices;determining, with the permission-management application, that the firstrequest specifies a first user is to be de-permissioned for a firstnative application among the plurality of different native applicationsand, in response, sending via a network, with the permission-managementapplication, instructions to a first client computing device to revokethe first user's authority to access the first native application;receiving, with the permission-management application, a second requestto manage permissions of one or more users to access resources withclient computing devices; and determining, with thepermission-management application, that the second request specifies asecond user is to be de-permissioned for a first network-accessibleapplication among the plurality of network-accessible applications and,in response, sending via a network, with the permission-managementapplication, instructions to an intermediary server to revoke the seconduser's authority to access the first network-accessible application,wherein the intermediary server is configured to automate control oflogin information for the first network-accessible application for theusers of the organization.
 2. The medium of claim 1, wherein theoperations comprise: logging a record indicative of the first request toan immutable data store.
 3. The medium of claim 2, wherein logging therecord indicative of the first request to the immutable data storecomprises: logging the record to a tamper-evident, immutable data store.4. The medium of claim 2, wherein logging the record indicative of thefirst request to the immutable data store comprises: segmenting therecord into a plurality of segments and logging the segments to aplurality of blockchains.
 5. The medium of claim 4, wherein logging thesegments to a plurality of blockchains comprises: storing the segmentsin leaf nodes of Merkle trees in the blockchains.
 6. The medium of claim1, wherein: the permission-management application is configured toprovide a centralized interface to manage permissions of a heterogenousset of monolithic native applications and hosted software-as-a-serviceapplications with a uniform interface.
 7. The medium of claim 6,wherein: the uniform interface includes a drag-and-drop graphical userinterface by which the first request and the second request areinitiated from one or more client computing devices.
 8. The medium ofclaim 6, wherein: the drag-and-drop user interface includes one or moregraphical regions representing one or more users and one or moregraphical regions representing at least some of the set of monolithicnative applications and hosted software-as-a-service applications. 9.The medium of claim 8, wherein: the operations comprise sendinginstructions to render the graphical user interface to the one or moreclient computing devices from which the first and second requests aresent to the permission-management application; and the instructions areconfigured to be rendered in a web browser to cause the web browser topresent the graphical user interface.
 10. The medium of claim 1,wherein: the permission-management application is configured totranslate a permission-grant request or de-permission request in aunified format by which permission-grant requests or de-permissionrequests for a plurality of different network-accessible applicationsare communicated to the permission-management system into anetwork-application-specific format compliant with an applicationprogram interface of a selected one of the plurality of differentnetwork-accessible applications.
 11. The medium of claim 10, wherein:the network-application-specific format is not compliant with anapplication program interface of an unselected one of the plurality ofdifferent network-accessible applications.
 12. The medium of claim 1,wherein sending instructions to the first client computing device torevoke the first user's authority to access the first native applicationcomprises: sending the instructions to revoke the first user's authorityto access the first native application to an agent executing on thefirst client computing device.
 13. The medium of claim 12, wherein theoperations comprise: receiving, with the agent executing on the firstclient computing device, the instructions to revoke the first user'sauthority to access the first native application; and in response toreceiving the instructions to revoke the first user's authority toaccess the first native application, changing or deleting a value storedon the first client computer effective to prevent the first user fromaccessing the first native application on the first client computingdevice.
 14. The medium of claim 13, wherein: the first nativeapplication is an offline application; and the changed or deleted valueis effective to prevent the first user from accessing the first nativeapplication on the first client computing device in the absence ofnetwork access.
 15. The medium of claim 1, wherein the operationscomprise: receiving, with the permission-management application, a thirdrequest to manage permissions of one or more users to access resourceswith client computing devices; and determining, with thepermission-management application, that the third request specifies athird user is to be granted permission for a second native applicationand, in response, sending, via a network, with the permission-managementapplication, instructions to a third client computing device to grantthe third user authority to access the second native application. 16.The medium of claim 1, wherein the operations comprise: receiving, withthe permission-management application, a fourth request to managepermissions of one or more users to access resources with clientcomputing devices; and determining, with the permission-managementapplication, that the fourth request specifies a fourth user is to begranted permission for a second network-accessible application and, inresponse, sending, via a network, with the permission-managementapplication, instructions to an intermediary server to grant the seconduser authority to access the second network-accessible application, thesecond network-accessible application being a web application accessibleby a web browser.
 17. The medium of claim 1, wherein: permissions formore than 1,000 users are managed for more than 5 native applicationsand more than 5 network-accessible applications.
 18. The medium of claim1, the operations comprising: steps for providing a centralized platformfor management of users within external applications.
 19. The medium ofclaim 1, the operations comprising: executing a plurality of enterpriseapplications on the client computing devices for which thepermission-management application manages access; and accessing aplurality of the network-accessible applications for which thepermission-management application manages access with the clientcomputing devices.
 20. A method, comprising: receiving, with one or moreprocessors executing a permission-management application, a firstrequest to manage permissions of one or more users to access resourceswith client computing devices, wherein: the permission-managementapplication is configured to manage permissions for users of anorganization to access a plurality of network-accessible applications;the plurality of different network-accessible applications havedifferent permission-management application program interfaces; and thepermission-management application is configured to manage permissionsfor users to access respective instances of a plurality of differentnative applications executing on the client computing devices;determining, with the permission-management application, that the firstrequest specifies a first user is to be de-permissioned for a firstnative application among the plurality of different native applicationsand, in response, sending via a network, with the permission-managementapplication, instructions to a first client computing device to revokethe first user's authority to access the first native application;receiving, with the permission-management application, a second requestto manage permissions of one or more users to access resources withclient computing devices; and determining, with thepermission-management application, that the second request specifies asecond user is to be de-permissioned for a first network-accessibleapplication among the plurality of network-accessible applications and,in response, sending via a network, with the permission-managementapplication, instructions to an intermediary server to revoke the seconduser's authority to access the first network-accessible application,wherein the intermediary server is configured to automate control oflogin information for the first network-accessible application for theusers of the organization.